Auf den Punkt gebracht ist React eine Bibliothek, mit der sich Benutzeroberflächen im Web erstellen lassen. React bedient allerdings nur einen kleinen Ausschnitt in der Webentwicklung, nämlich die Aufteilung und Gestaltung von Komponenten einer Webapplikation. Gehen man von einer klassischen MVC-Struktur im Client aus, übernimmt React die Aufgaben der View, also die Anzeige und die Kapselung der Anzeigelogik.

Wer sich erstmals mit React befasst, trifft auf zahlreiche vermeintlich neue Konzepte: Immutability, Value Objects, Unidirectional Dataflows, Identität, Gleichheit, Pure Functions, und und und. Nur die wenigsten dieser Begriffe sind neu, die meisten entstammen der funktionalen Programmierung, haben allerdings nie den Sprung in die Objektorientierung geschafft. Im Workshop „React Internals: Deep-Dive“ auf den React Days 2017 bringt Golo Roden den Teilenehmern alles an funktionalem Grundlagenwissen näher, das man für den produktiven und gelungenen Einsatz von React benötigt. Wir haben vorab mit Golo über die Vor- und Nachteile von React gesprochen und machen auch noch einen Schlenker zu seinem zweiten Workshop, in dem sich alles um Architekturen mit JavaScript dreht.

Golo, du hältst auf den React Days den Workshop „React Internals: Deep-Dive“. Was sind aus deiner Sicht überhaupt die grundlegenden Vorteile von React und wie unterscheidet es sich von anderen JS-Bibliotheken?

Golo Roden: Den ersten Punkt hast Du bereits angesprochen: React ist eine Bibliothek, kein Framework. Anders als zum Beispiel Angular konzentriert sich React auf eine einzige Aufgabe, nämlich das effiziente Rendern der Anzeige. Dieser Minimalismus ist aber keine Einschränkung, im Gegenteil: Ich kaufe bei React nicht die Katze im Sack, sondern habe einen weiteren kleinen, überschaubaren und klar abgegrenzten Lego-Baustein in der Hand, mit dem ich meine Anwendung aufbauen kann. Das ist genau das, was das Web groß und erfolgreich gemacht hat: Kleine, unabhängige Einheiten, die sich flexibel miteinander kombinieren lassen. Wer stattdessen einen großen monolithischen Klotz verwendet, macht sich dadurch extrem abhängig – von einem Werkzeug beziehungsweise vor allem auch von einem Hersteller.

Hinzu kommt für mich noch ein zweiter Aspekt: React ist eine JavaScript-Bibliothek, nicht mehr. Ja, es gibt JSX, aber man kann React auch ohne JSX benutzen. Dafür muss ich verstehen, wie JavaScript funktioniert. Lerne ich, besseres JavaScript zu schreiben, verbessern sich automatisch meine Kenntnisse in React und umgekehrt. Bei Angular zum Beispiel ist das anders: Hier muss ich zusätzlich auch noch zahlreiche Framework-spezifische proprietäre Konstrukte lernen, beispielsweise die diversen ng-*-Konstrukte. React ist da viel einfacher gestrickt, aber in dieser Einfachheit steckt eine enorme Eleganz. Und genau das zeichnet React aus: Sehr einfach, aber äußerst leistungsfähig.

Man sollte auch immer etwaige Nachteile oder Limitierungen erwähnen. Was wären dies deiner Meinung nach bei React? Wo siehst du noch Potenzial?

Roden: Die größte Hürde beim Einstieg in React ist das Ökosystem. React ist, wie schon gesagt, eigentlich sehr einfach. Auch wenn es möglich ist, React ohne jegliche Erweiterungen zu nutzen, verwenden die meisten Entwicklerinnen und Entwickler aber doch auch JSX. Dafür braucht man aber Babel. Auch der Einsatz von webpack ist sinnvoll. Und dabei zeigt sich ein großes Problem: Es greifen bei React zahlreiche Dinge ineinander, die jeweils für sich genommen sehr einfach sind, deren Verbund aber zumindest zu Beginn schwer zu greifen ist. Hier könnte mehr Dokumentation weiterhelfen, aber wirklich gute Inhalte für den Einstieg in React sucht man leider immer noch.

Ein anderer wichtiger Punkt, der den Einstieg häufig schwieriger macht als er sein müsste, ist die Verwendung von diversen Konzepten aus der Informatik, die nicht oder besser gesagt noch nicht zum Mainstream gehören. Anders als Angular ist React sehr stark von der funktionalen Programmierung geprägt, was einen maßgeblichen Anteil an der Eleganz von React hat. Allerdings kennen sich nach wie vor zu wenige Menschen mit funktionaler Programmierung aus, weil objektorientierte Sprachen wie C# und Java in vielen Unternehmen das Denken geprägt haben. Dieses vertraute Terrain zu verlassen, es loszulassen, das erfordert Mut, und das ist nicht leicht. Auch hierzu kann eine gute Dokumentation einen wichtigen Beitrag leisten.

Viele Begriffe, die einem bei einer ersten Beschäftigung mit React direkt begegnen sind nicht neu, sondern alte Bekannte. Aber sie gehören als Grundlagenwissen zur Basis, die man benötigt, um React produktiv einsetzen zu können. Wenn du uns drei Basics herauspicken müsstest, welche würdest du interessierten Entwicklern ans Herz legen?

Roden: Deine Frage unterstreicht letztlich genau meine Aussage zur funktionalen Programmierung nochmals, denn neu ist das alles nicht, nur zu wenig bekannt und verbreitet. Das meiner Meinung nach wichtigste Konzepte in React ist die Unveränderlichkeit (engl. Immutability), also der Ansatz, dass Daten sich im Lauf der Zeit nicht verändern. Ein klassisches Objekt ist ein wunderbares Beispiel, wie man es nicht machen sollte: Weil Objekte einen veränderlichen Zustand haben, erbt man einen riesigen Zoo an Problemen, insbesondere, wenn man Code parallelisiert. Doch auch in Single-Thread-Architekturen begegnet man regelmäßig diversen Problemen. Unveränderlichkeit löst viele dieser Probleme, indem einfach gesagt wird, dass sich ein Zustand nicht mehr ändern kann, wenn er einmal gesetzt ist. Dass das allerdings eine ganz andere Art zu entwickeln nach sich ziehen muss, liegt auf der Hand. Das bedeutet außerdem, dass man sich über Speicherverwaltung, das Typsystem, und zahlreiche andere Dinge Gedanken machen muss, da man nur dann die Feinheiten versteht, die das Konzept der Unveränderlichkeit mit sich bringt.

Das zweite wichtige Konzept in React ist der Abschied von einer bidirektionalen Datenbindung hin zu einem unidirektionalen Datenfluss (engl. Unidirectional Dataflow). Auf den ersten Blick fällt es vielen Entwicklerinnen und Entwicklern schwer, sich vorzustellen, wie eine UI-Technologie ohne bidirektionale Datenbindung funktionieren soll. Doch eigentlich ist es ganz leicht, wenn man den Ansatz einmal verstanden hat. Der Witz dabei ist, dass es tatsächlich viel leichter ist, nur unser Denken ist seit jeher ganz anders geprägt. Deshalb fällt uns der Umstieg so schwer. Was man durch die Unidirektionalität gewinnt, ist eine viel bessere Vorhersagbarkeit, wie sich die Anwendung in welcher Situation verhalten wird. Das ist ein großer Gewinn und vereinfacht die Entwicklung von korrekter Software dramatisch.

Das dritte wichtige Konzept ist eigentlich kein Konzept an sich, sondern eine Technologie: Lernt JavaScript! Wie schon gesagt verbessern gute Kenntnisse in JavaScript automatisch auch die Kenntnisse in React, und umgekehrt. Dazu gehört vor allem, JavaScript funktional zu verwenden, und die Ursprünge von JavaScript kennenzulernen. Dazu gehört auch der sichere Umgang mit den zahlreichen neuen Syntaxkonstrukten, die in den vergangenen Jahren aufgekommen sind. Leider wird das viel zu oft auf die Schlüsselwörter class und extends reduziert, die vor allem das objektorientierte Denken ansprechen sollen – doch leider ist genau das Falsche, wenn man sich ernsthaft mit React befassen möchte. Konzepte von funktionalen Sprachen zu lernen wären eventuell das, was ich jemandem raten würde: Dinge wie Map-Reduce, Lambdaausdrücke, Pure-Functions & Co. sollten zum Handwerkszeug gehören.

Du hältst außerdem noch den Workshop „Architektur mit JavaScript“ und besprichst dabei, wie man CQRS mit Node.js in Angriff nimmt. Was sind die schwierigsten Hürden, die es dabei zu meistern gilt?

Roden: Mit CQRS ist es sehr ähnlich wie mit React: Eigentlich ist das Entwurfsmuster sehr einfach, die Komplexität entsteht durch das Ökosystem. CQRS wird häufig mit DDD und Event-Sourcing in einen Topf geworfen. Die drei Konzepte passen sehr gut zueinander, lassen sich aber auch jeweils einzeln hervorragend anwenden. Trotzdem findet man kaum eine Einführung, die das sauber trennt. Das macht es sehr schwierig, weil insbesondere DDD als Methodik für Entwicklerinnen und Entwickler, die Objektorientierung und CRUD gewohnt sind, zunächst sehr fremd wirkt. Auch hier kann man viel beitragen, indem man diese Konzepte anschaulich und begreifbar macht.

Hinzu kommt außerdem noch, dass es sich dabei eben nur um Konzepte handelt, nicht um Technologien: Wer verstanden hat, wie CQRS, DDD und Event-Sourcing funktionieren, hat noch lange keine Implementierung. Diese zu bauen ist schwierig, weil es wenige Leitplanken gibt, und weil man sich dann häufig auch mit verteilten Architekturen beschäftigen muss, was den Aufwand nochmals steigert. Wir, das heißt meine Kollegen bei the native web und ich, haben uns in den vergangenen Jahren sehr intensiv mit der Frage befasst, wie sich diese Themen leichter zugänglich machen lassen. Unsere Antwort ist das wolkenkit, ein in Node.js entwickeltes Framework, das auf CQRS und Event-Sourcing basiert, und den Einsatz von DDD fördert. Doch auch hier muss man sich zuvor mit den Konzepten, die dahinterstehen, vertraut machen.

Was ist deiner Meinung nach die größte oder interessanteste Änderung im Bereich der Architektur? Eventgetriebene Architekturen oder eher Microservices? Oder ist es eine Mischung aus allem?

Roden: Das ist schwer zu sagen, aber ich glaube, die wichtigste Änderung ist, dass wir endlich im größeren Stil von Monolithen wegkommen: Der Gedanke, dass Technologien nicht systemrelevant werden dürfen, kommt langsam im Mainstream an. Das funktioniert aber nur dann, wenn wir Funktionseinheiten viel stärker voneinander entkoppeln und sauber über Schnittstellen trennen. Letztlich passiert genau das mit Micro- und Nanoservices.

Eventgetriebene Architekturen tragen ebenfalls ihren Teil dazu bei, denn gerade DDD zum Beispiel fordert dieser Entkopplung auf sprachlicher Ebene, indem begrenzte Kontexte (engl. Bounded Contexts) bewusst eingeführt werden. Dass das dann scheinbar zufälligerweise gut mit Microservices zusammenpasst, ist also in Wahrheit gerade kein Zufall: Letztlich sind es nur zwei Seiten der gleichen Medaille. Aufpassen muss man hier aber, wie so oft, dass man nicht dem Irrglauben verfällt, das Ei des Kolumbus gefunden zu haben: React, CQRS, DDD, Microservices & Co. sind alles faszinierende Themen, aber sie alle haben ihre Vorzüge und ihre Nachteile. Das richtige Werkzeug für die richtige Aufgabe auswählen zu können, ist heute wichtiger denn je. Das wiederum gelingt aber nur dem, der die konzeptionellen Unterschiede verstanden hat. Und um genau die geht es in meinen Workshops.

Geschrieben von: Hartmut Schlosser

Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.